Internet Video
Over that past few years, the technology for streaming video over the internet has developed rapidly. Among these developments are: Increased available bandwidth both wired and wireless, available to the user and new mobile devices introduced to the market, capable of displaying high quality video
These developments resulted in a state where the internet traffic is dominated by video streaming. The traditional method, of fully downloading a file prior to viewing it, results in a long delay between the request and the viewing and does not facilitate live video distribution. This state introduced a demand for instant viewing methods, in order to provide TV-like viewing experience.
Streaming Over UDP
User Datagram Protocol (UDP) was the first transport protocol used to stream video over an Internet protocol (IP) networks. Due to the real-time nature of video applications, the choice of the stateless UDP protocol was natural. The reliability advantage of the Transmission Control Protocol (TCP) was considered useless when delivering video, since the retransmitted data may arrive following its display time, in which case the retransmission was useless. The stateless nature of UDP enabled simultaneous serving of multiple user devices, using Multicast transmission.
Streaming of video over UDP is done primarily using real-time transport protocol (RTP) and real time streaming protocol (RTSP). These protocols typically enable playback functionalities such as Play, Pause, Rewind, Fast Forward, Record, etc. However, since UDP is not a native protocol of the internet, network firewalls and network address translation (NAT) devices block UDP streams by default and legacy proxy and cache servers did not function on UDP streams
Another shortage of this approach, using multicast transmission, is the fact that the same stream is being sent to all user devices. This results in packet drops in scenarios where the video stream bit rate was higher than the bit rate available for the user device. This, in turn, results in video streams that were not viewed properly by the user device.
These difficulties yielded the introduction of a streaming method which is based on the hypertext transfer protocol (HTTP) and transfer control protocol (TCP) protocols, which are native to the internet environment.
Progressive Download
Progressive Download, is a method where video is transferred to the user device as a file using the HTTP application layer protocol. As soon as enough video is received at the user device, it starts playing the video. Progressive download faces various problems, some which are illustrated below.
Insufficient Available Bandwidth
There are scenarios where the available bandwidth on a link between the video server and the user device is lower than the video stream BW. In such scenarios, the video will not be downloaded fast enough and as a result the user device will be starved resulting in intermittent stops in playback.
Fluctuations in the Available Bandwidth
The network connecting the server and the user device typically includes many links between routers, each having a different available bandwidth. The number of users sharing each link is large and varies over time. WiFi links, which are typically the last hop in the route, may exhibit drops in available bandwidth.
The aforementioned results in fluctuations in the available bandwidth for the session. In a scenario where the link bandwidth fluctuates over time the user may experience problems even though the average link bandwidth is higher than the nominal stream bandwidth. This may result due to local minimum in the link bandwidth which will not enable a continuous streaming.
Fluctuations in Video Encoding Bit-Rate (Variable Bit Rate (VBR) Stream)
The video encoder may encode different parts of the video stream in different bit-rates. This happen can locally, on a scale of a few seconds, even in case the encoder was configured to output a VBR stream. During periods when the encoded video bit-rate is higher than the average, it is possible that the available bit-rate for the user device is insufficient for continuous playback. In such a case the playback will freeze, even though on average the bit-rate available for the user device is sufficient for the video.
The Available Bandwidth is Too High
When the available bandwidth between the server and the user device is higher than the nominal stream bandwidth, video data is accumulated at the user device's video playback buffer. If the user device stops the video playback before the entire stream is played, all the accumulated data at the playback buffer is discarded without being watched. However, downloading data that will not be used is a waste of network resources.
Start/Seek Time
When a user device requests a certain remote video asset, the video playback does not start upon the arrival of the first video byte to the user device. Rather, the video playback is delayed, in order to allow accumulation of video playback buffer at the user device. This delay also occurs when the user device seeks forward or backward in the movie and its previously transmitted data becomes irrelevant. This delay has a typical length of several seconds, and it degrades the user experience.
TCP Utilization
The most common link layer protocol for video transmission over the Internet is TCP. The TCP protocol dynamically attempts to estimate the link's parameters (BW, Round Trip Time (RTT)) and adjust its transmission accordingly. It also attempts to share the available bandwidth evenly between TCP user devices. This probing functionality has a cost in term of transmission efficiency. As a result, a sender that knows exactly the available bandwidth for the stream may better utilize the link. An example for this under-utilization can be seen in Wang's work (B. Wang, 2004, “Multimedia Streaming via TCP: An Analytic Performance Study”), stating that good streaming of video over TCP requires available bandwidth of twice the mediaBW.
Improvements to Progressive Download
Despite much inefficiency, the progressive download method gained popularity and became the streaming approach of choice for many content providers. The attempts to solve its problems are presented here.
Caching
A content delivery network (CDN) is a network of caching proxy servers. Ideally, a caching server will be located as close as possible to the user device. A CDN shortens the distance between the user device and the server, resulting in a wider channel with less bandwidth fluctuation. However, the solution for the bandwidth problems is only partial, since the route between the user device and the proxy server may still exhibit problems of insufficient or fluctuating bandwidth.
Bit Rate Throttling
Bit rate throttling is a feature in a video streaming server that controls the rate in which data is being transmitted to the user. The video streaming server analyzes the video file sent to the user, determines its encoding bit rate, and sets its transmission bit rate accordingly. When a new user starts receiving video, the video streaming server sets the transmission bit rate to be higher than the encoding bit rate, in order to reduce the startup delay at the user device.
The above solutions attempt to address the problem of having too much available bandwidth, and also attempt to improve start/seek delay.
Adaptive Bit-Rate (ABR)
ABR is a method that enables each user device to receive the appropriate video, according to its available bandwidth. The video is encoded in several versions, each in a different bit-rate. The user device senses the available bandwidth, and selects the appropriate version accordingly.
Using ABR, each version of the stream is encoded in segments. A segment is a part of the stream that can be concatenated to its subsequent segment from a different version in a way which appears seamless to the player. Segment duration is typically 2-10 seconds.
An adaptive streaming user device measures its available bandwidth and playback buffer state, and according to those inputs requests the segment of the appropriate version.
The ABR method attempts to resolve the problem of having too little and too much bandwidth, as well as addressing fluctuation in bandwidth. ABR also improves the start/seek delay by selecting versions with smaller sizes when the playback buffer is low. However, ABR also creates a new quality of experience (QoE) problem, whereby the quality of the received stream is inconsistent.
As described in the previous paragraph, TCP connections share the bandwidth equally. But equal bandwidth does not mean equal video quality, as in the following example:
Two user devices are sharing the same channel of 4 mbps. One is a HD TV, whose video is encoded in the following versions: HIGH—4 mbps, MED—3 mbps, LOW—2 mbps. The other is a smartphone, with a lower screen resolution, whose video has the following versions: HIGH—2 mbps, MED—1 mbps, LOW—0.5 mbps.
The TCP associated with each user device will attempt to achieve an equal share of the channel's bandwidth, thus each user device will be allocated 2 mbps. In this example, the smartphone will experience a high video quality, while the HD TV will suffer from a low video quality.
Inequality in the QoE (or video quality) can occur when all user devices are using the same device as well. For example, when encoding a video sequence, the encoder may require more bits for complex scenes than to a simple scene. In a scenario where one user device watches a complex scene, which requires high bit rate for a certain quality, and another user device watches a simple scene, which requires a lower bit rate for the same quality, the TCP, being oblivious to video quality, will receive equal bandwidth for both user devices, hence causing video quality inequality.
Adjustable bit rate (ABR) attempts to solve the problems of fluctuating available bandwidth and fluctuating video encoding bit-rate, but does so based only on data received at the user device, which produces limited results comparing to the proposed solution.
Like reference numbers and designations in the various drawings indicate like elements.